情境驅動的必要性

多數人在剛開始接觸敏捷時，往往會問一個問題：「我們應該用 Scrum 還是 Kanban？」

這樣的提問就像是在問：「我現在生病了，是該吃成藥 A 還是成藥 B？」這背後的假設是只要找到正確的方法，問題自然就能解決。

但軟體開發的世界並不像人體一樣有一套通用的生理機制。每個團隊的規模不同、任務性質不同、技術基礎不同，甚至連組織文化也大不相同。曾經的成功經驗，搬到別的地方不一定管用。別人覺得超棒的做法，拿來用反而可能成為阻力。例如：

• 每個團隊的起點不一樣

  • 有的團隊成員都是資深工程師，能快速採用自動化測試
  • 有的團隊剛轉型，連持續整合工具都還不熟悉

• 外部限制差異很大

  • 金融、醫療等領域必須符合嚴格法規，流程要保留審計軌跡
  • 網路新創則追求快速實驗，流程越簡單越好

• 組織文化影響深遠

  • 有的公司重視層級與權責，決策必須逐級核准
  • 有的公司則推崇去中心化，團隊可以快速做主

也因此，敏捷從來就不是一套「照著做就會成功」的處方箋，反而像是一道道「根據情境做選擇」的申論題。

就以最常見的 Scrum 為例。Scrum 本身只提供了最基本核心的骨架：角色、事件與產出物的定義。但並沒有規定任務該怎麼拆、文件該寫到多細、回顧會議該怎麼開、遇到風險該如何處理，這些都需要團隊根據自身情況來決定。

這也是許多團隊導入敏捷後感到挫折的原因之一。他們照著書上寫的流程跑了一輪，卻發現問題依舊存在，甚至變得更混亂。原因並不是「敏捷無效」，而是忽略了敏捷本身就是要讓團隊主動做選擇，而不是被動照著做。

Disciplined Agile（簡稱 DA）正是基於這個觀點發展出來，它並不告訴團隊該用哪一套方法，而是提供團隊一套架構與工具，幫助團隊根據「團隊的情境」來做出「最適合團隊的選擇」。

因為現實世界中，不存在一套放諸四海皆準的最佳實踐（Best practice），我們能擁有的，只有更合適當下的「適切實踐」（Contextual practice）。

常見敏捷方法的盲點

Scrum 是目前全球使用最廣泛的敏捷框架之一。它提供了一套簡潔的流程架構，定義了角色、事件與產出物，對於剛接觸敏捷的團隊來說，是很好的起點。

但問題就在這裡，這只是起點。

許多團隊在導入 Scrum 後，會進入一種「照流程走就對了」的思維模式。每日站會、迭代規劃、回顧會議，流程都跑完了，但實際工作還是卡卡的，品質也沒有明顯提升。

常見的問題像是：

• 當環境變動太快，固定長度的迭代反而成為負擔
• 如果團隊缺乏跨職能能力，Scrum 的自組織精神就很難落實
• 無法直接從真實客戶身上得到回饋，功能價值都建立在老闆的假設之上

這是因為 Scrum 並不會解決所有問題。它只是提供了一個基本框架，真正的挑戰在於「這個框架之下，我們要怎麼運作，才最適合我們的情境？」

甚至隨著組織規模擴大，面對更多跨團隊合作的挑戰，單靠 Scrum 已經不敷使用。這時就會有人轉向更大一層的框架，例如 SAFe（Scaled Agile Framework）、LeSS（Large-Scale Scrum） 等等，希望透過「標準化的進階方法」來解決規模化的問題。

但現實卻常是另一種狀況：

• SAFe 的流程太繁瑣，導致團隊回到文件與報表導向的工作方式
• LeSS 強調精簡，但需要組織文化一同配合精簡，讓每個團隊都用相同一套的工作方式

這些框架各自有其設計目的與使用情境，但都不是萬靈丹。若不釐清自身問題與需求，就貿然導入新的框架，只會讓問題互相疊加。

所以與其問「哪一套框架好」，更好的問題應該是：「我們現在遇到的核心問題是什麼？這個框架有幫助解決它嗎？如果沒有，我們能怎麼調整或混合使用？」

架構不是終點，而是工具箱。團隊可以根據需求，從中選擇合適的做法，拼湊出最適合自己團隊的工作方式。團隊甚至可以從 Scrum、Kanban、XP、SAFe、DevOps 等多個來源中擷取做法，自由組合出最有利的模式。

框架不是拿來照抄的，而是幫助團隊思考該怎麼做出更好的選擇。

DA 的「情境適配」觀念

有些人會說：「我們就照著上次成功的做法來吧！」這句話聽起來合理，畢竟過去成功的經驗值得參考，但問題是誰能保證這次的情境跟上次一模一樣嗎？

現實情況是：每個團隊都有自己的獨特性，就連同一家公司裡的不同團隊，也可能因為任務內容、技術基礎、合作模式等因素而大相逕庭。

DA 最核心的特色，就是承認「沒有一套方法適合所有團隊」。與其追求單一框架的標準化，不如提供一張「地圖」，幫助團隊在不同情境下，做出最合適的選擇。

因此 DA 提供了目標導向的方式協助引導團隊選擇，把在各階段會遇到的挑戰，整理成一系列流程目標（Process Goals）。每個流程目標底下，提供不同的實踐選項，並清楚列出優缺點。這讓團隊能根據情境，挑選適合的做法，而不是被迫遵守單一流程。

在選擇工作方式時，必須考慮以下七大情境因子（Scaling Factors）：團隊規模、地理分布、組織分布、技能可用性、合規要求、技術複雜度及領域複雜度，這些因素都會直接影響團隊應該採用什麼樣的工作方式，不同的情境因子組合，會導致完全不同的最佳解。簡單的說，如果忽略這些條件，一味複製別人的成功經驗，就像拿著別人的處方箋，卻沒做任何診斷，風險自然極高。

敏捷不是照抄某套框架，而是能夠根據情境做出最佳選擇，並隨時不斷試驗、調整，逐步找到最適合的方法。

這種「情境適配」的精神讓團隊不再被單一方法限制，而是有能力在複雜多變的環境中，找到屬於自己的路。

結論：成功的關鍵不是照本宣科，而是持續學習與調整

DA 強調「引導式持續改善（Guided Continuous Improvement, GCI）」，因為成熟的敏捷團隊，最關鍵的能力不是「正確執行流程」，而是能：

• 看見現有做法的限制
• 找到可以嘗試的新策略
• 透過實驗與回顧，不斷優化自己的流程

這就像健身訓練一樣。不是拿到一份教練課表就會變壯，而是要持續回顧自己的狀況、調整飲食與訓練內容，才可能真的讓身體越來越健康。

事實上，敏捷導入最常失敗的原因，往往不是做錯了什麼，而是不願改變任何東西。

有些團隊只是表面上套用了敏捷框架，但：

• 每天開站會只是進度報告，沒人在意阻礙有沒有被解決
• 迭代結束後例行辦回顧會議，但從來沒有真的調整做法
• 任務流程還是用接力賽的方式處理，只是套上了敏捷的名字

這樣的敏捷，其實只是一種「假裝變革」。

成功的關鍵從來不是「選了什麼框架」，而是「團隊是否願意持續學習、嘗試改變、累積經驗，並調整做法？」

也許一開始是參考了 Scrum 的迭代節奏，後來加入了 Kanban 的視覺化與 WIP 限制，再根據團隊特性微調了需求管理方式、測試流程、部署節奏。這些拼湊出來的工作方式，就是團隊專屬的 WoW（Way of Working）。不是因為它「長得像某個框架」，而是因為它「真的對我們有幫助」。

DA 不會說「這樣做最好」，而是說「這些選擇適合什麼情境」，幫助團隊釐清思路、做出判斷、持續改善。

沒有哪一套方法是完美的，但是會持續演化的工作方法，才有可能變得越來越好。